home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group94b.txt / 000038_icon-group-sender _Sat Sep 3 22:48:20 1994.msg < prev    next >
Internet Message Format  |  1995-02-09  |  3KB
  1. Received: by cheltenham.cs.arizona.edu; Sun, 4 Sep 1994 10:40:21 MST
  2. To: icon-group@cs.arizona.edu
  3. Subject: Re: Icon - still alive??
  4. Message-Id: <778632500@mse>
  5. Date: Sat, 03 Sep 94 22:48:20 UTC
  6. From: whm@mse.com (William H. Mitchell)
  7. Errors-To: icon-group-errors@cs.arizona.edu
  8.  
  9.     >Nick Williams writes:
  10.  
  11.     >What was Icon intended for then? Is it supposed to allow highly portable
  12.     >programming by putting huge restrictions on what Icon programmers can
  13.     >do? I bet not (why else would there be a preprocessor?, or &features for
  14.     >that matter?).  ...
  15.  
  16. I think Icon was intended to provide a mechanism to do research in the
  17. design and implementation of high-level language facilities.  Fortunately
  18. for today's Icon users, the research turned out pretty well and as a side
  19. effect a powerful language is available free of charge. 
  20.  
  21.     >Forcing programmers to go hack the RTL code from which icont and iconc
  22.     >are made or to write C function wrappers to system routines (plus Icon
  23.     >wrappers as well), then relink the relevant libraries and executables
  24.     >(or use loadfunc()) just to make them think twice before they use a
  25.     >system dependent function is CRAZY! ...
  26.  
  27.     >Besides, Icon could turn out to be useful for more than just processing
  28.     >text (why are graphics facilities would have been added otherwise?).
  29.  
  30. I think there's an issue of what's useful to the most people.  Most
  31. non-graphical programs can be written in plain old Icon.  With the graphic
  32. extensions, now many graphics programs are in Icon's domain. 
  33.  
  34. I just went through an MKS toolkit manual (the MKS toolkit is a collection
  35. of ported UNIX commands) and counted programs that could and could not be
  36. easily written in Icon.  I got 47 that could be written in Icon and 12 that
  37. either couldn't be written in Icon or would be inoordinately difficult.
  38. That's about 4:1, which is less than I'd hoped for, but consider this:  how
  39. many lines of code would be required would be required to write all the
  40. programs in each category?  The non-Icon programs did include some
  41. signficant programs like cpio and find, but many were trivial:  chomd,
  42. date, df, du, and id. 
  43.  
  44. To tell you the truth, before typing this note I'd always lamented Icon's lack
  45. of system-level facilities, but considering the domain of programming problems,
  46. I now have to concede that I think Icon's focus is right on target.
  47.  
  48. But here's a thought for those interested in Icon programs that do serious
  49. system-level stuff:  Link in a copy of Perl and write a couple of
  50. interface routines -- sort of like SNOBOL4's CODE function! 
  51.  
  52.      /------------------------------\         /----------------\
  53.     /      William H. Mitchell       \       / 7120 E. Kiva Way \
  54.    /  Mitchell Software Engineering   \o----/ Tucson, AZ, 85715  \
  55.    \ Consulting/Development/Training  /     \    602-577-6431    /
  56.     \   OO Methods/C++/Icon/UNIX     /       \    whm@mse.com   /
  57.      \------------------------------/         \----------------/
  58.  
  59.